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Abstract 


The IETF policies about rights in Contributions to the IETF are 
designed to ensure that such Contributions can be made available to 
the IETF and Internet communities while permitting the authors to 
retain as many rights as possible. This memo details the IETF 
policies on rights in Contributions to the IETF. It also describes 
the objectives that the policies are designed to meet. This memo 
obsoletes RFCs 3978 and 4748 and, with BCP 79 and REC 5377, replaces 
Section 10 of RFC 2026. 
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Definitions 


The following definitions are for terms used in the context of this 
document. Other terms, including "IESG", "ISOC", "IAB", and "RFC 
Editor" are defined in [RFC2028]. 


a. 


"Contribution": any submission to the IETF intended by the 
Contributor for publication as all or part of an Internet-Draft or 
RFC (except for RFC Editor Contributions described in Section 4 
below) and any statement made within the context of an IETF 
activity. Such statements include oral statements in IETF 
sessions as well as written and electronic communications, made at 
any time or place, that are addressed to: 


the IETF plenary session, 

any IETF working group or portion thereof, 

any Birds of a Feather (BOF) session, 

the IESG, or any member thereof on behalf of the IESG, 

the IAB, or any member thereof on behalf of the IAB, 

any IETF mailing list, including the IETF list itself, any 
working group or design team list, or any other list functioning 
under IETF auspices, 

o the RFC Editor or the Internet-Drafts function (except for RFC 
Editor Contributions, as described in Section 4 below). 


000000 


Statements made outside of an IETF session, mailing list, or other 
function, that are clearly not intended to be input to an IETF 
activity, group, or function are not IETF Contributions in the 
context of this document. 


"Contributor": an individual submitting a Contribution. 


"Indirect Contributor": any person who has materially or 
substantially contributed to a Contribution without being 
personally involved in its submission to the IETF. 


"Copyright": the legal right granted to an author in a document or 
other work of authorship under applicable law. A "copyright" is 
not equivalent to a "right to copy". Rather a copyright 
encompasses all of the exclusive rights that an author has ina 
work, such as the rights to copy, publish, distribute and create 
derivative works of the work. An author often cedes these rights 
to his or her employer or other parties as a condition of 
employment or compensation. 


"IETF": in the context of this document, the IETF includes all 
individuals who participate in meetings, working groups, mailing 
lists, functions, and other activities that are organized or 
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initiated by ISOC, the IESG, or the IAB under the general 
designation of the Internet Engineering Task Force (IETF), but 
solely to the extent of such participation. 


f. "IETF Documents": RFCs and Internet-Drafts that are used in the 
IETF Standards Process as defined in 1(g). This is identical to 
the "IETF stream" defined in [RFC4844]. 


g. "IETF Standards Process": the activities undertaken by the IETF in 
any of the settings described in 1(a) above. 


h. “IETF Trust": a trust established under the laws of the 
Commonwealth of Virginia, USA, in order to hold and administer 
intellectual property rights for the benefit of the IETF. 


i. "Internet-Draft": temporary documents used in the IETF Standards 
Process. Internet-Drafts are posted on the IETF web site by the 
IETF Secretariat. As noted in Section 2.2 of RFC 2026, Internet- 
Drafts have a nominal maximum lifetime of six months in the IETF 
Secretariat’s public directory. 


j. "Legend Instructions": the standardized text that is maintained by 
the IETF Trust and is included in IETF Documents and the 
instructions and requirements for including that standardized text 
in IETF Documents. The text and instructions are posted from time 
to time at http://trustee.ietf.org/license-info. 


k. "RFC": the publication series used by the IETF among others. RFCs 
are published by the RFC Editor. Although RFCs may be superseded 
in whole or in part by subsequent RFCs, the text of an RFC is not 
altered once published in RFC form. (See [RFC2026] Section 2.1.) 


1. "Reasonably and personally known": something an individual knows 
personally or, because of the job the individual holds, would 
reasonably be expected to know. This wording is used to indicate 
that an organization cannot purposely keep an individual in the 
dark about certain information just to avoid the disclosure 
requirement. 


m. "Non-IETF documents": Internet-Drafts that are submitted to the 
RFC Editor independently of the IETF Standards Process. (See 
Section 4.) 
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Introduction 


In all matters of copyright and document procedures, the intent is to 
benefit the Internet community and the public at large, while 
respecting the legitimate rights of others. 


Under the laws of most countries and current international treaties 
(for example the "Berne Convention for the Protection of Literary and 
Artistic Work" [Berne]), authors obtain numerous rights in the works 
they produce automatically upon producing them. These rights include 
copyrights, moral rights, and other rights. In many cases, if the 
author produces a work within the scope of his or her employment, 
most of those rights are usually assigned to the employer, either by 
operation of law or, in many cases, under contract. (The Berne 
Convention names some rights as "inalienable", which means that the 
author retains them in all cases.) 


In order for Contributions to be used within the IETF Standards 
Process, including when they are published as Internet-Drafts or 
RFCs, certain limited rights must be granted to the IETF Trust, which 
then grants the necessary rights to the IETF. In addition, 
Contributors must make representations to the IETF Trust and the IETF 
regarding their ability to grant these rights. 


Section 1 provides definitions used in these policies. Sections 3 
and 4 of this document explain the rationale for these provisions. 
Sections 1, 2, 5, and 6 of this document are normative, the other 
sections are informative. RFC 3979 (BCP 79) [RFC3979] deals with 
rights, including possible patent rights, in technologies developed 
or specified as part of the IETF Standards Process. This document is 
not intended to address those issues. This memo obsoletes RFCs 3978 
[RFC3978] and 4748 [RFC4748] and, with RFC 3979 (BCP 79) and 
[RFC5377], replaces Section 10 of RFC 2026 [RFC2026]. 


This document is not intended as legal advice. Readers are advised 
to consult their own legal advisors if they would like a legal 
interpretation of their rights or the rights of the IETF Trust 
[RFC4371] in any Contributions they make. 


1. No Retroactive Effect 
This memo does not retroactively obtain additional rights from 


Contributions that predate the date that the IETF Trust announces the 
adoption of these procedures. 
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3. Exposition of Why These Procedures Are the Way They Are 
3.1. Rights Granted in Contributions 


The IETF Trust and the IETF must obtain the right to publish an IETF 
Contribution as an RFC or an Internet-Draft from the Contributors. 


A primary objective of this policy is to obtain from the document 
authors only the non-exclusive rights that are needed to develop and 
publish IETF Documents and to use IETF Contributions in the IETF 
Standards Process and potentially elsewhere. 


The authors retain all other rights, but cannot withdraw the above 
rights from the IETF Trust and the IETF. 


It is important to note that under this document, Contributors are 
required to grant certain rights to the IETF Trust (see Section 
5.3.), which holds all IETF-related intellectual property on behalf 
of the IETF community. The IETF Trust will, in turn, grant a 
sublicense of these rights to all IETF participants for use in the 
IETF Standards Process (see Section 5.4.). This sublicense is 
necessary for the standards development work of the IETF to continue. 
In addition, the IETF Trust may grant certain other sublicenses of 
the rights that it is granted under this document. In granting such 
other sublicenses, the IETF Trust will be guided and bound by 
documents such as [RFC5377]. 


3.2. Rights to Use Contributions 


It is important that the IETF receive assurances from all 
Contributors that they have the authority to grant the IETF the 
rights that they claim to grant because, under the laws of most 
countries and applicable international treaties, copyright rights 
come into existence when a work of authorship is created (but see 
Section 3.5 below regarding public domain documents), and the IETF 
cannot make use of IETF Contributions if it does not have sufficient 
rights with respect to these copyright rights. The IETF and its 
participants would run a greater risk of liability to the owners of 
these rights without this assurance. To this end, the IETF asks 
Contributors to give the assurances in Section 5.6 below. These 
assurances are requested, however, only to the extent of the 
Contributor’s reasonable and personal knowledge. (See Section 1(1).) 


3.3. Right to Produce Derivative Works 
The IETF needs to be able to evolve IETF Documents in response to 


experience gained in the deployment of the technologies described in 
such IETF Documents, to incorporate developments in research, and to 
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react to changing conditions on the Internet and other IP networks. 
The IETF may also decide to permit others to develop derivative works 
based on Contributions. In order to do this, the IETF must be able 
to produce derivatives of its documents; thus, the IETF must obtain 
the right from Contributors to produce derivative works. Note that 
the right to produce translations is required before any Contribution 
can be published as an RFC, to ensure the widest possible 
distribution of the material in RFCs. The right to produce 
derivative works, in addition to translations, is required for all 
IETF Standards Track documents and for most IETF non-Standards Track 
documents. There are two exceptions to this requirement: documents 
describing proprietary technologies and documents that are 
republications of the work of other standards organizations. 


The right to produce derivative works must be granted in order for an 
IETF working group to accept a Contribution as a working group 
document or otherwise work on it. For non-working group 
Contributions where the Contributor requests publication as a 
Standards Track RFC, the right to produce derivative works must be 
granted before the IESG will issue an IETF Last Call and, for most 
non-Standards Track, non-working group Contributions, before the IESG 
will consider the Internet-Draft for publication. Occasionally a 
Contributor may not want to grant publication rights or the right to 
produce derivative works before finding out if a Contribution has 
been accepted for development in the IETF Standards Process. In 
these cases, the Contributor may include a limitation on the right to 
make derivative works in the form specified in the Legend 
Instructions. A working group can discuss the Contribution with the 
aim to decide if it should become a working group document, even 
though the right to produce derivative works or to publish the 
Contribution as an RFC has not yet been granted. However, if the 
Contribution is accepted for development, the Contributor must 
resubmit the Contribution without the limitation notices before a 
working group can formally adopt the Contribution as a working group 
document. The IETF Trust may establish different policies for 
granting sublicenses with respect to different types of Contributions 
and content within Contributions (such as executable code versus 
descriptive text or references to third-party materials). The IETF 
Trust’s policies concerning the granting of sublicenses to make 
derivative works will be guided by RFC [RFC5377]. 


The IETF has historically encouraged organizations to publish details 
of their technologies, even when the technologies are proprietary, 
because understanding how existing technology is being used helps 
when developing new technology. But organizations that publish 
information about proprietary technologies are frequently not willing 
to have the IETF produce revisions of the technologies and then 
possibly claim that the IETF version is the "new version" of the 
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organization’s technology. Organizations that feel this way can 
specify that a Contribution be published with the other rights 
granted under this document but may withhold the right to produce 
derivative works other than translations. 


In addition, IETF Documents frequently make normative references to 
standards or recommendations developed by other standards 
organizations. Since the publications of some standards 
organizations are not public documents, it can be quite helpful to 
the IETF to republish, with the permission of the other standards 
organization, some of these documents as RFCs so that the IETF 
community can have open access to them to better understand what they 
are referring to. In these cases, the RFCs can be published without 
the right for the IETF to produce derivative works. In both of the 
above cases, in which the production of derivative works is excluded, 
the Contributor must include a special legend in the Contribution, as 
specified in the Legend Instructions, in order to notify IETF 
participants about this restriction. 


3.4. Rights to Use Trademarks 


Contributors may wish to seek trademark or service mark protection on 
any terms that are coined or used in their Contributions. The IETF 
makes no judgment about the validity of any such trademark rights. 
However, the IETF requires each Contributor, under the licenses 
described in Section 5.3 below, to grant the IETF Trust a perpetual 
license to use any such trademarks or service marks solely in 
exercising rights to reproduce, publish, discuss, and modify the IETF 
Contribution. This license does not authorize the IETF or others to 
use any trademark or service mark in connection with any product or 
service offering. 


3.5. Contributions Not Subject to Copyright 


Certain documents, including those produced by the U.S. government 
and those which are in the public domain, may not be protected by the 
same copyright and other legal rights as other documents. 
Nevertheless, we ask each Contributor to grant to the IETF the same 
rights he or she would grant, and to make the same representations, 
as though the IETF Contribution were protected by the same legal 
rights as other documents, and as though the Contributor could be 
able to grant these rights. We ask for these grants and 
representations only to the extent that the Contribution may be 
protected. We believe they are necessary to protect the ISOC, the 
IETF Trust, the IETF, the IETF Standards Process, and all IETF 
participants, and because the IETF does not have the resources or 
wherewithal to make any independent investigation as to the actual 
proprietary status of any document submitted to it. 
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6. Copyright in RFCs 


As noted above, Contributors to the IETF (or their employers) retain 
ownership of the copyright in their Contributions. This includes 
Internet-Drafts and all other Contributions made within the IETF 
Standards Process (e.g., via e-mail, oral comment, and otherwise). 
However, it is important that the IETF (through the IETF Trust) own 
the copyright in documents that are published as RFCs (other than 
Informational RFCs and RFCs that are submitted as RFC Editor 
Contributions). Ownership of the copyright in an RFC does not 
diminish the Contributors’ rights in their underlying contributions, 
but it does prevent anyone other than the IETF Trust (and its 
licensees) from republishing or modifying an RFC in RFC format. In 
this respect, Contributors are treated the same as anybody else: 
though they may extract and republish their own Contributions without 
limitation, they may not do so in the RFC format used by the IETF. 
And while this principle (which is included in Section 5.9 below) may 
appear to be new to the IETF, it actually reflects historical 
practice and has been observed for many years through the inclusion 
of an ISOC or IETF Trust copyright notice on all RFC documents since 
the publication of RFC 2026. 


Non-IETF Documents 


This document only relates to Contributions made as part of the IETF 
Processes. Other documents that are referred to as Internet-Drafts 
and RFCs may be submitted to and published by the RFC Editor 
independently of the IETF Standards Process. Such documents are not 
covered by this document, unless the controlling entity for that 
document stream, as described in [RFC4844] chooses to apply these 
rules. Non-IETF Contributions must be marked appropriately as 
described in the Legend Instructions. See the RFC Editor web page 
for information about the policies concerning rights in RFC Editor 
Documents; for other document streams, the controlling entity must be 
contacted. See Section 11 for a declaration from the IAB on this 
matter. 


Rights in Contributions 
1. General Policy 


By submission of a Contribution, each person actually submitting the 
Contribution and each named co-Contributor is deemed to have read and 
understood the rules and requirements set forth in this document. 
Each Contributor is deemed, by the act of submitting a Contribution, 
to enter into a legally-binding agreement to comply with the terms 
and conditions set forth in this document. 
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The Contributor is further deemed to have agreed that he/she has 
obtained the necessary permissions to enter into such an agreement 
from any party that the Contributor reasonably and personally knows 
may have rights in the Contribution, including, but not limited to, 
the Contributor’s sponsor or employer. 


No further acknowledgment, signature, or other action is required to 
bind a Contributor to these terms and conditions. The operation of 
the IETF and the work conducted by its many participants is dependent 
on such agreement by each Contributor, and each IETF participant 
expressly relies on the agreement of each Contributor to the terms 
and conditions set forth in this document. 


5.2. Confidentiality Obligations 


No information or document that is subject to any requirement of 
confidentiality or any restriction on its dissemination may be 
submitted as a Contribution or otherwise considered in any part of 
the IETF Standards Process, and there must be no assumption of any 
confidentiality obligation with respect to any Contribution. Each 
Contributor agrees that any statement in a Contribution, whether 
generated automatically or otherwise, that states or implies that the 
Contribution is confidential or subject to any privilege, can be 
disregarded for all purposes, and will be of no force or effect. 


5.3. Rights Granted by Contributors to the IETF Trust 


To the extent that a Contribution or any portion thereof is protected 
by copyright or other rights of authorship, the Contributor and each 
named co-Contributor grant a perpetual, irrevocable, non-exclusive, 
royalty-free, world-wide, sublicensable right and license to the IETF 
Trust under all such copyrights and other rights in the Contribution: 


a. to copy, publish, display, and distribute the Contribution, in 
whole or in part, 


b. to prepare translations of the Contribution into languages other 
than English, in whole or in part, and to copy, publish, display, 
and distribute such translations or portions thereof, 


c. to modify or prepare derivative works (in addition to 
translations) that are based on or incorporate all or part of the 
Contribution, and to copy, publish, display, and distribute such 
derivative works, or portions thereof unless explicitly disallowed 
in the notices contained in a Contribution (in the form specified 
by the Legend Instructions), and 
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d. to reproduce any trademarks, service marks, or trade names which 
are included in the Contribution solely in connection with the 
reproduction, distribution, or publication of the Contribution and 
derivative works thereof as permitted by this Section 5.3, 
provided that when reproducing Contributions, trademark and 
service mark identifiers used in the Contribution, including TM 
and (R), will be preserved. 


5.4. Sublicenses by the IETF Trust 


The IETF Trust will sublicense the rights granted to it under Section 
5.3 to all IETF participants for use within the IETF Standards 
Process. This license is expressly granted under a license agreement 
issued by the IETF Trust, which can be found at 
http://trustee.ietf.org/license-info. 


This license is expressly granted under a license agreement issued by 
the IETF Trust and must contain a pointer to the full IETF Trust 
agreement. 


In addition, the IETF Trust may grant additional sublicenses of the 
licenses granted to it hereunder. In doing so, the IETF Trust will 
comply with the guidance provided under RFC 5377 [RFC5377]. 


5.5. No Patent License 


The licenses granted in Section 5.3 shall not be deemed to grant any 
right under any patent, patent application, or other similar 
intellectual property right disclosed by the Contributor under BCP 79 
[RFC3979] or otherwise. 


5.6. Representations and Warranties 


With respect to each Contribution, each Contributor represents that, 
to the best of his or her knowledge and ability: 


a. The Contribution properly acknowledges all Contributors, including 
Indirect Contributors. 


b. No information in the Contribution is confidential, and the IETF, 
IETF Trust, ISOC, and its affiliated organizations may freely 
disclose any information in the Contribution. 


c. There are no limits to the Contributor’s ability to make the 
grants, acknowledgments, and agreements herein that are reasonably 
and personally known to the Contributor. 
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d. The Contributor has not intentionally included in the Contribution 
any material that is defamatory or untrue or which is illegal 
under the laws of the jurisdiction in which the Contributor has 
his or her principal place of business or residence. 


e. All trademarks, trade names, service marks, and other proprietary 
names used in the Contribution that are reasonably and personally 
known to the Contributor are clearly designated as such where 
reasonable. 


5.7. No Duty to Publish 


The Contributor, and each named co-Contributor, acknowledges that the 
IETF has no duty to publish or otherwise use or disseminate any 
Contribution. The IETF reserves the right to withdraw or cease using 
any Contribution that does not comply with the requirements of this 
Section 5. 


5.8. Trademarks 


Contributors who claim trademark rights in terms used in their IETF 
Contributions are requested to state specifically what conditions 
apply to implementers of the technology relative to the use of such 
trademarks. Such statements should be submitted in the same way as 
is done for other intellectual property claims. (See [RFC3979] 
Section 6.) 


5.9. Copyright in RFCs 


Subject to each Contributor’s (or its sponsor’s) ownership of its 
underlying Contributions as described in Section 5.6 (which ownership 
is qualified by the irrevocable licenses granted under Section 5.3), 
each Contributor hereby acknowledges that the copyright in any RFC in 
which such Contribution is included, other than an RFC that is an RFC 
Editor Contribution, shall be owned by the IETF Trust. Such 
Contributor shall be deemed to assign to the IETF Trust such 
Contributor’s copyright interest in the collective work constituting 


such RFC upon the submission of such RFC for publication, and 
acknowledges that a copyright notice acknowledging the IETF Trust’s 
ownership of the copyright in such RFC will be included in the 
published RFC. 


5.10. Contributors’ Retention of Rights 
Although Contributors provide specific rights to the IETF, it is not 


intended that this should deprive them of their right to exploit 
their Contributions. To underscore this principle, the IETF Trust is 
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directed to issue a license or assurance to Contributors, which 
confirms that they may each make use of their Contributions as 
published in an RFC in any way they wish, subject only to the 
restriction that no Contributor has the right to represent any 
document as an RFC, or equivalent of an RFC, if it is not a full and 
complete copy or translation of the published RFC. 


6. Legends, Notices and Other Standardized Text in IETF Documents 


The IETF requires that certain standardized text be reproduced 
verbatim in certain IETF Documents (including copies, derivative 
works, and translations of IETF Documents). Some of this 
standardized text may be mandatory (e.g., copyright notices and 
disclaimers that must be included in all RFCs) and some may be 
optional (e.g., limitations on the right to make derivative works). 
The text itself, as well as the rules that explain when and how it 
must be used, is contained in the Legend Instructions. The Legend 
Instructions may be updated from time to time, and the version of the 
standardized text that must be included in IETF Documents is that 
which was posted in the Legend Instructions on the date of 
publication. 


The IETF reserves the right to refuse to publish Contributions that 
do not include the legends and notices required by the Legend 
Instructions. 


It is important to note that each Contributor grants the IETF Trust 
rights pursuant to this document and the policies described herein. 
The legends and notices included in certain written Contributions 
such as Internet-Drafts do not themselves convey any rights. They 
are simply included to inform the reader (whether or not part of the 
IETF) about certain legal rights and limitations associated with such 
documents. 


It is also important to note that additional copyright notices are 
not permitted in IETF Documents except in the case where such 
document is the product of a joint development effort between the 
IETF and another standards development organization or is a 
republication of the work of another standards development 
organization. Such exceptions must be approved on an individual 
basis by the IAB. 


7. Security Considerations 


This memo relates to the IETF process, not any particular technology. 
There are security considerations when adopting any technology, but 
there are no known issues of security with IETF Contribution rights 
policies. 
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Changes since RFC 3978 


This document represents a significant reorganization and rewording 
of RFC 3978, along with a number of substantive changes. 


The most basic change is to limit this document to the rights that a 
Contributor grants to the IETF Trust when making a Contribution. All 
sublicenses of rights for the use of IETF Documents must be provided 
by the IETF Trust. (See Section 5.4.) 


Material added from RFC 4748 that recognized the IETF Trust. 


Most of the material relating to RFC Editor documents has been 
removed since the RFC Editor maintains their own rules and processes 
for RFC Editor documents. Renamed these documents to "non-IETF 
documents". Added section 11 from the IAB discussing this topic. 


Changes in the definitions section include defining the terms 
"Contribution", "Indirect Contributor", "Copyright", "IETF Trust", 
and "Legend Instructions", as well as minor tweaks to some of the 
other definitions. 


The responsibility for the text of notices has been given to the IETF 
Trust and removed from this document. (See Section 6.) 


Clarified that Contributors enter into a legally binding contract 
when they submit a Contribution. (See Section 5.1.) 


The right to produce derivative works provided by the Contributor to 
the IETF Trust is not limited to being within the IETF Standards 
Process. 


Made it clear that this document does not deal with patent licenses. 
(See Section 5.5.) 


Clarified the ownership of the Copyrights to IETF Documents. (See 
Section 5.9.) 


Clarified the rights retained by authors of IETF Contributions. (See 
Section 5.10.) 
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Declaration from the IAB 


The IAB discussed the IPR documents during its most recent call. It 
unanimously decided that the IAB stream is to be covered by the 
incoming IPR document. It is our understanding that IAB stream 
documents’ IPR are then automatically covered by the outbound rights 
that the IETF Trust will establish based on the advice in [RFC5377]. 


We also want to stress that, for any change in the inbound rights for 
streams other than the IETF and IAB streams, there needs to be a 
stream-dependent discussion and approval process, as indicated in RFC 
4844, "The RFC Series and RFC Editor" [RFC4844], section 4.2.3. 


To that extent, section 4 of the document should explicitly mention 
that the IRTF, the Independent, and any possible future streams are 
not covered by the document. 


For the IAB, 


Olaf Kolkman 
April 4, 2008 
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